Custom Software

Some scenarios for custom software

General information

There are many reasons to use custom software. The main and most general one is: you have a data problem that no (affordable) product on the market can solve by itself. Replacing well-maintained and well-tested standard software is not a reason to use custom software, because, as a rule of thumb, custom software is more expensive and less powerful than good standard tools. Therefore, most custom software we build for our customers is not stand-alone, but rather a plugin or extension of one or more standard products.

Consequently, if our customers have a problem that can be solved with software, we first check whether there are standard solutions that can solve the problem fully or partially.

These are some scenarios where custom software can make things easier:

Custom interfaces

Imagine you have two information systems you want to exchange data, but there is no standard interface on the market. For example, you have a Product Information Management System (PIM) holding your product hoierarchy and product data and you want to provide the data to a component Content Management System (CCMS) for the following use cases:

• Assign nodes in the product structure (like selected products or articles or entire product families, or even all products) to the topics in the CCMS to express their product validity. This can be used in variant management to publish the same manual for different product configurations.
• Fill topics with technical data tables from the PIM as the "single source of truth".

If there is no standard interface between the two products that you have is available, there is no standard way to solve this problem. Since most server-based information systems have some sort of documented Application Programming Interface (API), it is possible to write an interface module that reads the product data from the PIM and uploads it to the CCMS, either on every relevant change or periodically.

Migration

If you need to move existing data into a system, either from a previous system that you are replacing or from file-based data in the file system, these basic tasks must be fulfilled:

• Read the data from the current information source.
• Convert the data structures read from the source into structures compatible with the target system. How good the degree of automation is that can be achieved depends on many parameters:
  • How systematically is the source data structured?
  • Does the granularity of the source and target modules match?
  • Are taxonomies compatible?
  • Does the source allow structures that can't be expressed in the target?
  • Are there systematic ways to map them to valid target structures?
  • …

We have deep experience with migrations of various types of data. One typical case is: conversion of legacy documentation written with Microsoft Word into modules for a component Content Management System (CCMS). This normally includes significant manual work, for example, to establish re-use, straighten terminology etc., but infrastructural tasks typically can be well automized.

What we can do for you

• Definition of your requirements.
• Check whether the requirements can be partially or completely fulfilled with standard software products.
• Suggest a solution, discuss it with you and describe it in an adequate way.
• Implementation.